Idef0

DESCRIVERE PER CAPIRE
IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
1 X SNOD O SNODO X Link 4
Precedenc
e

CAPIRE PER MIGLIORARE
Link Caso
"b"

UOB
3

Uno Strumento per la Descrizione
dei Processi Aziendali

Ing. A. Colombo Modellazione Aziendale Pag. 1

IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

SOMMARIO

Uno Strumento per la Descrizione dei Processi Aziendali 1
Descrizione 2
Le Celle 4
Regole semantiche delle frecce ICOM 5
Bundling 6
Squiggle 7
Funzionalità Standard 8
Matrici 12
Proprietà 13
Node Tree Diagrams 18

Figura 1 - Il concetto di processo IDEFØ.......................................................................3
Figura 2 - Esempio di cella con controllo multiplo..........................................................4
Figura 3 – Bundling “totale” di un ICOM.........................................................................6
Figura 4 – Bundling “parziale” di un ICOM.....................................................................6
Figura 5 – Esempio di bundling di tipo “fan-out”.............................................................7
Figura 6 – Esempio di “squiggle”....................................................................................7
Figura 7 - Diagramma “Context” di IDEFØ.....................................................................8
Figura 8 - Decomposizione IDEFØ.................................................................................9
Figura 9 - IDEFØ Model Propagation (percorso).........................................................10
Figura 10 - IDEFØ Cost Generation.............................................................................11
Figura 11 – Report di sintesi “Cost Centers by Functions”..........................................12
Figura 12 – Node Tree Diagram...................................................................................18

Tabella 1 - Posizionamento delle frecce........................................................................5
Tabella 2 - Attributi di “Diagramma” IDEFØ.................................................................13
Tabella 3 – Attributi di “Modello”...................................................................................13
Tabella 4 – Attributi di “Function/Activity”.....................................................................14
Tabella 5 - Attributi di “Cost Driver”..............................................................................15
Tabella 6 – Attributi di “ICOM”......................................................................................16
Tabella 7 – Attributi di “Indicatore”................................................................................17

Descrizione


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

Il metodo IDEFØ (Integrated DEfinition for Function Analysis), elaborato con lo scopo di
descrivere i sistemi di produzione, si basa sulla tecnica SADT (Structured Analysis and
Design Technique) e consente di individuare a livelli di dettaglio mano a mano crescenti
(approccio top-down) le attività in cui si scompone un processo ed i flussi informativi tra di
esse. È stato sviluppato presso “US Air Force Program for Integrated Computer Aided
Manufacturing (ICAM)” e fa parte di una famiglia di 16 metodi IDEF, da IDEFØ ad IDEF14
(incluso IDEF1 ed 1X), in cui si rappresentano innumerevoli informazioni come ad
esempio informazioni di tipo “object-oriented design” (IDEF4), per la simulazione (IDEF2),
di tipo “user-interface design” (IDEF8), per i modelli organizzativi (IDEF12).
Rispetto al modello standard, definito dall’ICAM e riportato in SA2001 sono state apportate
delle modifiche e personalizzazioni onde soddisfare l’esigenza di UIB di utilizzare il
modello per il disegno dei processi nell’ambito di un progetto Qualità.
I componenti fondamentali del modello sono i processi o attività (rappresentati da celle
rettangolari) e le interazioni tra i processi del modello, nonché tra i processi e l’ambiente
esterno, espresse in termini di input, vincoli, risorse (rappresentate da frecce entranti
rispettivamente da sinistra, dall’alto e dal basso del rettangolo) e output (uscenti da destra
del rettangolo).

A-0 MODELLO DI
PROCESSO (IDEF0)

CONTROL

INPUT OUTPUT
FUNCTION/ACTIVITY

1

MECHANISM

Figura 1 - Il concetto di processo IDEFØ


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

Le Celle

Le Celle rappresentano Attività del Sistema/Processo e sono descritte da un verbo o una
frase scritta all’interno della Cella stessa (Titolo). Oltre al Nome, alle Celle viene
assegnato un Numero che non è altro che l’ultima cifra del Codice di Nodo (si veda più
avanti). Il Numero di Cella viene apposto nella parte inferiore destra della Cella.
I Connettori collegati ad una Cella rappresentano oggetti fisici o informazioni necessarie
per svolgere l’Attività, o prodotti dall’Attività. I Connettori non rappresentano quindi
solamente un flusso di Attività (come nei Diagrammi di Flusso), ma i vincoli che
definiscono le Celle e pertanto sono corredate di un’Etichetta che le descrive in modo
chiaro e completo.
Il lato della Cella dal quale un Connettore entra o esce indica il ruolo del Connettore che
può essere Input, Controllo o Output. I Connettori in entrata (lato superiore o sinistro della
Cella) indicano gli oggetti necessari per svolgere quell’Attività. Il Connettore in uscita (lato
destro) indica i dati o gli oggetti fisici generati dallo svolgimento dell’Attività. Procedendo
da sinistra a destra l’Attività trasforma gli elementi di Input in elementi di Output e quindi la
Cella rappresenta la transizione da uno stato prima e dopo l’Attività.
Il Controllo descrive le condizioni o circostanze che governano la trasformazione operata
dall’Attività e, di conseguenza, si capisce che il ruolo dell’Input e del Controllo sono
decisamente diversi; anzi la distinzione tra i due elementi è di fondamentale importanza
per capire come opera il Sistema/Processo. L’Input viene trasformato dall’attività.
Il lato inferiore della Cella è riservato per indicare il Meccanismo, che può essere la
persona o il dispositivo che svolge l’Attività. Riassumendo, l’Input e l’Output definiscono il
“cosa” è fatto dall’Attività; il Controllo indica il “perché” e il Meccanismo indica il “come”.
Le Celle rappresentano un insieme di Attività correlate e non semplicemente Attività a sé
stanti. Una può svolgere una funzione diversa a seconda di combinazioni diverse dei suoi
elementi di Input, Output e Controllo che vengono chiamate instanziazioni della Cella. Su
ogni lato di una Cella ci può essere più di un connettore.

S p e c i f ic h e
del C a r a t t e r is t ic h e
P r o d o tto d e g li
F in it o U t e n s ili

S p e c if ic h e d i
E le n c o I s tr u z io n i
d e lle P a r t i
A s s e m b l a g g io d 'A s s e m b l a g g i o

6

Figura 2 - Esempio di cella con controllo multiplo


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

Regole semantiche delle frecce ICOM

Gli ICOM assumono un preciso significato a seconda di come sono posizionati rispetto alla
cella attività.

Freccia Funzione Lato della cella Esempio

Oggetti o dati che un’attività
Input richiede per il suo Da sinistra
svolgimento.

Definisce perché e come
un’attività viene svolta. Per
Verso il basso sul
Control esempio in una lavorazione
lato superiore
meccanica il “control” può
essere il ciclo.

Quando l’attività in questione
è descritta in maggior
Verso il basso dal
Call dettaglio in un’altra attività,
lato inferiore
quest’ultima è richiamata
(“call”) dalla prima.

Oggetti o dati generati
Output Da destra
dall’attività.

Gli “strumenti” per svolgere
l’attività. Verso l’alto sul
Mechanism
Possono essere uomini, lato inferiore
macchine o sistemi.

Tabella 1 - Posizionamento delle frecce


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

Bundling

Uno stesso ICOM può essere associato in toto a più di un’attività, come in questo caso il
control “Norme”.

Norme

GESTIONE
DELLA
COMMESSA
1

RIESAME DEL
CONTRATTO

2

CONTROLLO
DEL
PROGETTO
3

Figura 3 – Bundling “totale” di un ICOM

Oppure parti di un ICOM possono essere associate ad attività diverse, come nell’esempio
seguente.

Norme

GESTIONE Norme progettuali
Norme contrattuali
DELLA
COMMESSA
1

RIESAME DEL
CONTRATTO

2

CONTROLLO
DEL
PROGETTO
3

Figura 4 – Bundling “parziale” di un ICOM


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

La figura seguente mostra un esempio di un altro tipo di bundling di tipo “fan-in”, mentre i
precedenti erano di tipo “fan-out”.

PRODUZIONE Motore
MOTORE

1

PRODUZIONE
CARROZZERIA Carrozzeria

2

ASSEMBLAGGIO
Vettura
3

Figura 5 – Esempio di bundling di tipo “fan-out”

Squiggle

È il simbolo grafico usato per associare un ICOM al proprio nome, qualora questo debba
essere posizionato lontano

Input

ATTIVITA

1

Figura 6 – Esempio di “squiggle”


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

Funzionalità Standard

IDEFØ in SA2001 comprende le seguenti funzionalità standard:

1. Context ovvero A-0 Diagram
2. Creare un Constraint Diagram (Child Decomposition)
3. Node Tree Diagrams
4. IDEFØ Model Propagation
5. IDEFØ Cost Generation
6. IDEFØ Matrici

1. Context or A-Ø Diagram

Il diagramma di contesto IDEFØ è il più alto livello di rappresentazione del modello e
contiene solo un processo. E’ utilizzato per definire il contesto di mappatura dei
macroprocessi e fornire delle informazioni generiche. Il modellatore inizia la mappatura dei
processi con tale diagramma padre e, successivamente, lo scompone in ulteriori
diagrammi figli creando una relazione gerarchica. Per ogni diagramma di contesto bisogna
definire:

• Il “Contesto” che identifica la materia soggettiva del modello come parte di un insieme più grande,
delimitandone i confini e descrivendo le interfacce esterne che fissano in maniera puntuale cosa il
soggetto è e cosa non è.
• Il “Punto-di-vista” dal quale la materia soggettiva viene descritta che determina cosa può essere “visto”
nell’ambito del contesto e sotto quale angolatura. Definisce la posizione dell’autore in quanto
osservatore del Processo, a beneficio dei “lettori”. A seconda del tipo di lettore (management, tecnici,
clienti, etc.) si possono adottare diversi Punti-di-vista che stabiliscono l’importanza da attribuire ai diversi
aspetti da includere od omettere.
• Il “Proposito” o ragione per cui il modello viene creato (definire le specifiche funzionali di un nuovo
Sistema, reingegnerizzare un Processo esistente, diagnosticare eventuali malfunzionamenti operativi)
che ne determina lo scopo, la profondità e la struttura

A-0 Processo di un'azienda PROPOSITO:
generica (CONTESTO) Definire un modello di Sistema di Gestione per la
(IDEF0) Qualità abbastanza generale e generico da poter essere
utilizzato da qualsiasi azienda come punto di partenza
per la descrizione del proprio modello reale.
PUNTO DI VISTA:
E' quello dei componenti di un Gruppo di Lavoro
appositamente costituito nell'ambito del Club Qualità
della UIB.

soddisfazione cliente

requisiti clienti

prodotto
Processo di
risorse
un'azienda Comunicazioni risultati analisi ai Fornitori
generica
0
A0

addetti
terze parti

Figura 7 - Diagramma “Context” di IDEFØ


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

2. Creare un Constraint Diagram (Child Decomposition)

Dopo aver disegnato il “Context Diagram”, lo si scompone nei processi che lo
compongono, creando o collegando il “Constraint diagram”. IDEFØ Constraint diagram
descrive i sottoprocessi (sub-processes) di cui è composto il “Context Diagram” (livello1) o
il “Constraint diagram” ( per i livelli successivi al primo). Il metodo non consente di inserire
più di 6 sottoprocessi in ogni modello IDEF successivo al livello “context”; così come
consiglia di non utilizzare più di ¾ livelli di dettaglio onde consentire una migliore lettura
dei modelli stessi.

A135 PRODUZIONE
ED EROGAZIONE
SERVIZI (IDEF0)

piano della
qualità
spec.prod.
crit. produz.

Livello
ordini fornit. LG 7.5.1

PIANIFICAZ. validaz. proc.
piano produz.
RQ 7.5.2

1
PRODUZION E
produz.
contr. produz.
1
VALIDAZIONE RQ 7.5.1
PROCESSI pr ocessi
PRODUZIONE crit. rintracc.
validati
LG 7.5.2
RQ 7.5.2 2

FB rilav.
FABBRICAZIONE
fornit. accett. prodotto
propr. LG 7.5.4
RQ 7.5.3 3
RQ 7.5.4
clienti
A1353
MONITOR. E REG A354
MISU RAZ.
pr od. validato
RQ 7.6 4

IMMAG./
CONSEGNA prod.
PRODOTTO consegnato
RQ 7.5.5 5
A1353
FABBRICAZIONE
(IDEF0)
MANTENIM.
PRODOTTO pr od.
processi validati mantenuto
LG 7.5.4 6
piano di produz.

Prelievo materiale
Distinta tecnica
di produzione Disegno schema attrezzatura
1 Materia le con
buono di prelivo ciclo di lavoraz.

piano controlli
Operatore

Lavorazione Semilavorato Meccanico
Prod meccanica
2

contr . produz.
Macchinista

Oper atore Controllo di produzione
intermedio Semilavorato Meccanico Controllato

3
Aggiornamento Ciclo Lavorazione

crit. rintracc.

Prod

Assemblaggio Prodotto Finito X

Livello 4

2 Operatore

Figura 8 - Decomposizione IDEFØ


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

3. Model Propagation

Con tale funzionalità si trasferiscono, in automatico, le “ICOM” presenti nel diagramma
padre al diagramma figlio (child) e viceversa.
Si attiva dal menu “Tools, IDEF Utilities, IDEFØ Model Propagation”. Con questo comando
si collega il nome del modello del diagramma padre IDEFØ a tutti i diagrammi figli,
risultando così un utile strumento di lavoro per la creazione di un diagramma IDEFØ figlio
nel caso in cui non si è precedentemente creato un modello figlio.

Figura 9 - IDEFØ Model Propagation (percorso)

4. Tunneling

Una volta definito, come detto sopra, l’ambito di propagazione del modello (che può
limitarsi anche ad un solo padre/figlio), mediante il commando “Reports/Balance” è
possibile propagare gli ICOM da padre a figlio e viceversa. Come risultato di tale
operazione, alcuni ICOM risulteranno marcati con il segno di “tunnel” () che indica la
mancanza di origine/destinazione.


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

5. Cost generation

Con il modello IDEFØ è possibile effettuare un’analisi di tipo “ABC” (Activity Based
Costing).
Ogni informazione relativa al costo (frequenza, cost driver, cost pool, costo dell’attivita,
ecc.) deve essere inserita come attributo di ciascuna attività (function/activity) IDEFØ.
Dopo aver inserito nel modello i dati è possibile generare in automatico il costo di ogni
attività sia nel modello esaminato (figlio) che nel modello padre, come sintesi del primo.
Per generare il costo di un’attività:
da Tools menu, selezionare IDEF Utilities, IDEFØ Cost Generation.
Selezionare il diagramma e clickare su “Cost”. SA2001 calcolerà il costo di ogni attività.
Riaprendo il diagramma, il costo è visualizzato nell’oggetto “Function/Activity”. E’ inoltre
possibile ottenere un report di sintesi dei costi delle attività.

Figura 10 - IDEFØ Cost Generation


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

Figura 11 – Report di sintesi “Cost Centers by Functions”

Matrici

Per i modelli IDEFØ, SA2001 prevede le seguenti matrici standard:

• IDEFØ Function/Activity to ICOM: tale matrice rappresenta e descrive le relazioni di
Input/output/vincoli (controlli)/Risorse con le attività.
• IDEFØ Function/Activity to Cost Driver: tale matrice associa ad ogni attività il relativo cost driver.


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

Proprietà

Nel seguito sono indicate le informazioni contenute nel modello IDEFØ sia standard che
personalizzate.

1. Proprietà dei Diagrammi IDEFØ

Name
Form
Model Define >> (vedi
“Model”)
Diagram status
Working
Draft
Recommended
Publication
Diagram Text (Descrizione del
diagramma)
Used at (Se usato in altri modelli)
Project (Progetto cui appartiene)
Revision (Revisione)
UpdateDate (Data della revisione)
C-Number (Cronologia di creazione)
Page No
Reader
Reader (nome)
Reader date
Swim (da non usare)
Lanes
Notes
Swim Lanes
Hrizontal
Vertical
None
Tabella 2 - Attributi di “Diagramma” IDEFØ

2. Proprietà di Model

È utilizzato solo nell’IDEFØ context diagram.

Name
Introduction Description
Pur pose
Viewpoint
Node Tree Diagram
Time Frame As is / To Be
ABC Cost Multiplier ($ / $K / $M)
Override Decomps
Symbol Graphic Comment

Tabella 3 – Attributi di “Modello”


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

1. Function/Activity (model object)

FUNCTION/ Tabella 4 – Attributi di “Function/Activity”
ACTIVITY

5

Simbolo Grafico
Name
Description Descrizione
Related UOB’s Define Dimmed
Project Planning Tempo
Time measure
Fixed Time Yes / No
Budgeted Cost
Fixed Cost
Actual Cost
Milestone Yes / No
Summary Task Yes / No
Priority Low….High
WBS Code
ABC Frequency
Cost driver Define (vedi)
GENERALITÀ Ciclo Qualità Act, Check, Do, Plan
Macroprocesso (menu)
Requisiti ISO
REQUISITI Attività Conoscenza Define
Attitudini Define
Competenza Define
Documento Define >> (vedi ICOM)
Quality Cost Prevention
Inspection
Rework
Scrap
Operations
Quality Error rate
Statistics
First-run Yeld
Classification
Type Retention
Inspection
Operation
Transportation
Value External
added custm.
Internal
custm.
Other busin.s
No-value
Need Essential
Bypass
Rework
Duplication


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

•

2. Cost Driver/Indicatore di prestazione (Dictionary Object)

Nella Enciclopedia non personalizzata per UIB questo oggetto si chiamava solamente
“Cost Driver” e stava ad indicare qualsiasi fattore che fa accumulare costi ad un’attività.
Ogni attività può avere più di un cost driver e per ognuno di essi si può indicare un centro
di costo (“Cost Center”) che a sua volta può essere derivato da altri centri di costo
(“Underlying Cost Centers”).

Name
Inrtroduction Description
Cost
Variable Yes /No
Cost Center Define >> Name
Description
Total Cost
center
Underlying Define
Cost
Center
Gestione Elaborazione Define >> “Persona”
Indicatore
Verifica Define >> “Persona”
Approvazione Define >> “Persona”
Modifica Define >> “Persona”
Accesso Define >> “Persona”

Tabella 5 - Attributi di “Cost Driver”


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

3. ICOM Arrow (model object)

Nome

Simbolo Grafico
Name
Definition Glossary Text
IDEF1X (non
Attributi utilazzato)
RISORSE ICOMeccanism
Role (Ruolo) Define
Persona Define
DOCUMENTI Define v
Introduction Descrizione
Gestione
Documentazio
ne
Elaborazion Persona >> Define
e
Verifica Persona >> Define
Approvazion Persona >> Define
e
Modifica Persona >> Define
Accesso Persona >> Define
Frequenza (campo
Modifica libero)
Archiviazion Persona >> Define
e
Validità (campo
libero)
Posizione (campo
documento libero)
cartaceo
Posizione (campo
documento libero
elettronico
Tipo
documento
Istruzione
Manuale
Modulo
Procedura
Registrazion
e
Altri tipo Define >> Descriptio
documento n
Stato
Documentazio
ne

Tabella 6 – Attributi di “ICOM”


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

4. Indicatore/Cost Driver (Dictionary Object)

Come già detto precedentemente, gli indicatori (di prestazione) non esistono come
definition autonoma (N.B. non devono essere confusi con la definition “Performance
Measure” che riguarda le prestazioni dell’intero processo misurate attraverso il
“benchmarking” con i concorrenti), ma sono state inserite nello stesso “pool” dei “Cost
Drivers).

INDICATORE
(parametro) :
Generalità
IControlOM Indicatore di Define (vedi
prestazioni attività)
INDICATORE
(parametro)
Gestione
Elaborazione Persona Define
Verifica Persona Define
Approvazione Persona Define
Modifica Persona Define
Frequenza
modifica
Accesso Persona Define
INDICATORE
(parametro):
valori
Valore (campo
obiettivo libero)
Range (campo
accettabilità libero)
Range (campo
allarme libero)
Range (campo
d’intervento libero)

Tabella 7 – Attributi di “Indicatore”


IDEFØ
PROCESS O WNER

REFEREN T U OB
A 2

Cas o
"a"
Prece denc
U OB e UO B
Precedenc
e

Link Caso
"b"

UOB
3

Node Tree Diagrams

Dopo aver utilizzato Child diagrams per scomporre i processi è possibile creare un “Node
Tree Diagrammi” per visualizzare la gerarchia tra i sottoprocessi (albero dei processi).
Il diagramma “Node Tree” consente di ottenere in automatico, in un’unica
rappresentazione, i diversi livelli di scomposizione gerarchica IDEFØ

I processi di un'azienda
meccanica (scomposizione
gerarchica) (Node Tree)

A0 I processi di
un'azienda
meccanica

A0 A0 A0 Misurazione, A0 Gestione
Responsabilita' Realizzazione Analisi e Risorse
Direzione del prodotto Miglioramento

A0 A0 Gestione A0 Produzione A0
Pianificazione Ordini Infrastrutture
produzione

A0
Lavorazione
meccanica

A0 Prelievo
materiale di
produzione

A0
Saldatura

A0 Controllo di
produzione
intermedio

Figura 12 – Node Tree Diagram


Idef0

Recommended

Recommended

More Related Content

More from Arnaldo Colombo

More from Arnaldo Colombo (19)

Recently uploaded

Recently uploaded (16)

Idef0